feat: Full Endpoint Resolution from EndpointContext#2313
Conversation
| } else if (!Strings.isNullOrEmpty(endpoint)) { | ||
| audienceString = endpoint; |
There was a problem hiding this comment.
Confirm this behavior is correct
There was a problem hiding this comment.
The GDC-H audienceString's endpoint should match with endpoint set inside the TransportChannelProvider.
The logic is that for a GDC-H flow, the resolved endpoint will be either the clientsettings endpoint or transportchannel endpoint if set. This matches the behavior below as either the clientSettings or transportchannel's endpoint.
ClientSettings will only be set to the Transportchannel if it doesn't have an endpoint already set by the user. EndpointContext's resolvedEndpoint already takes this into consideration.
There was a problem hiding this comment.
The else block is kept as the custom endpoint could be set as "" (empty string). URI.create("") does not throw an exception, so it is caught in this else block.
3bc8392 to
bdbaab1
Compare
| throw new IllegalArgumentException("The universe domain value cannot be empty."); | ||
| } | ||
| // Universe Domain defaults to the GDU if it's not provided by the user. | ||
| resolvedUniverseDomain = universeDomain() != null ? universeDomain() : GOOGLE_DEFAULT_UNIVERSE; |
There was a problem hiding this comment.
Can we default the universe domain to GDU instead of introducing a new field resolvedUniverseDomain? In addition, can we move the universe domain resolution logic to build()? The validation above can be done there as well. I know this method is already being called from build(), but determining universe domain feels like a separate step that should be done before determining endpoint.
There was a problem hiding this comment.
Can we default the universe domain to GDU instead of introducing a new field resolvedUniverseDomain?
Do we still need resolvedUniverseDomain?
There was a problem hiding this comment.
I planned to remove it and use GDU by default, but I think there is a small edge case. Found it when running the IT GDCH tests, specifically regarding:
L190's ClientContext.create(...) creates an EndpointContext. Nothing is passed in via the universeDomain getter as it's a GDC-H flow, but the universe domain would be set to GDU by default.
L192's createStub() will create the Stub and it takes the params from the ClientContext (which has the GDU as the universe domain) and it will fail the GDC-H logic block.
I'm not sure the way that the IT GDC-H tests are set is makes sense (or if I'm missing something), specifically regarding explicitly creating the ClientSettings -> ClientContext -> StubSettings steps. But I think it shows that doing this is possible by the user.
I learned towards keeping the resolvedUniverseDomain so that the user can differentiate between what the user configuration and what the resolved universe domain is (null, GDU, user configured). This would possibly be done in a future enhancement as a getter.
There was a problem hiding this comment.
I learned towards keeping the resolvedUniverseDomain so that the user can differentiate between what the user configuration and what the resolved universe domain is (null, GDU, user configured)
Makes sense. Please see my new comments regarding resolvedUniverseDomain, I think it's better to make it not nullable, but maybe there is a edge case preventing us from doing so.
| abstract String getServiceName(); | ||
|
|
||
| @Nullable | ||
| public abstract String getUniverseDomain(); |
There was a problem hiding this comment.
Do we need to expose a getter for universe domain? I guess it is for StubSettings?
There was a problem hiding this comment.
This is for the for logic that connects ClientContext <-> StubSettings. I believe it was added a while back for reasons and this getter is (ideally) only for StubSettings usage.
There was a problem hiding this comment.
Yeah, for every new ClientSettings, it seems that we have to duplicate it in StubSettings as well.
gax-java/gax/src/main/java/com/google/api/gax/rpc/EndpointContext.java
Outdated
Show resolved
Hide resolved
gax-java/gax/src/main/java/com/google/api/gax/rpc/EndpointContext.java
Outdated
Show resolved
Hide resolved
gax-java/gax/src/main/java/com/google/api/gax/rpc/EndpointContext.java
Outdated
Show resolved
Hide resolved
| private String determineUniverseDomain() { | ||
| // Do not set the universe domain for GDC-H | ||
| if (usingGDCH()) { | ||
| return null; |
There was a problem hiding this comment.
Can we return GDU here instead of null? And make resolvedUniverseDomain not nullable? I see that resolvedUniverseDomain is used multiple places later, it is probably good now but may easily introduce null pointer exceptions later.
There was a problem hiding this comment.
The resolvedUniverseDomain is what is stored in the ClientContext and StubSettings (not the user configured universe domain). Following the GDC-H case above, it's possible to manually construct the StubSettings and ClientContext and each would construct the EndpointContext. If we set the resolvedUniverseDomain to the GDU by default, then it would fail every case as the Universe Domain can never be set for GDC-H (must be null).
--
Edit: I updated the logic so that it is non-null
| throw new IllegalArgumentException( | ||
| "Universe domain configuration is incompatible with GDC-H"); | ||
| } else if (customEndpoint == null) { | ||
| return buildEndpointTemplate(serviceName(), GOOGLE_DEFAULT_UNIVERSE); |
There was a problem hiding this comment.
Can we use resolvedUniverseDomain if we default it to GDU?
| throw new IllegalArgumentException("The universe domain value cannot be empty."); | ||
| } | ||
| // Universe Domain defaults to the GDU if it's not provided by the user. | ||
| resolvedUniverseDomain = universeDomain() != null ? universeDomain() : GOOGLE_DEFAULT_UNIVERSE; |
There was a problem hiding this comment.
I learned towards keeping the resolvedUniverseDomain so that the user can differentiate between what the user configuration and what the resolved universe domain is (null, GDU, user configured)
Makes sense. Please see my new comments regarding resolvedUniverseDomain, I think it's better to make it not nullable, but maybe there is a edge case preventing us from doing so.
| abstract String getServiceName(); | ||
|
|
||
| @Nullable | ||
| public abstract String getUniverseDomain(); |
There was a problem hiding this comment.
Yeah, for every new ClientSettings, it seems that we have to duplicate it in StubSettings as well.
| return new AutoValue_EndpointContext.Builder().setSwitchToMtlsEndpointAllowed(false); | ||
| } | ||
| @Nullable | ||
| public abstract String resolvedUniverseDomain(); |
There was a problem hiding this comment.
Do we expect resolvedUniverseDomain to be used by anything outside of this class? If not, I think we can make the this method and the setter in the builder package private (I don't think we can make it completed private though due to AutoValue limitations).
There was a problem hiding this comment.
Actually on second thought, I think you're right. I've made it package private. I originally used it as the value I set in the ClientContext, but I can just follow what we are doing with endpoint and pass the user set values for that. This way the resolvedUniverseDomain can be non-null (default to GDU).
blakeli0
left a comment
There was a problem hiding this comment.
LGTM. Please add Javadocs before merging.
| @Nullable | ||
| public abstract String serviceName(); | ||
|
|
||
| @Nullable |
There was a problem hiding this comment.
Please add some Javadocs to the getter here and setter below
|
|

Features: